home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-11-26 | 3.7 KB | 79 lines | [TEXT/ttxt] |
- Release Notes for MacTCP 2.0.6
- Copyright ©1994, Apple Computer, Inc.
- All rights reserved.
- November 22, 1994
-
- MacTCP version 2.0.6 is an update release.
- MacTCP version 2.0.5 was only released internal to Apple.
- MacTCP 2.0.6 contains the following improvements over MacTCP 2.0.4
- and earlier versions:
-
- Domain Name Resolver:
- ---------------------
-
- • Inbound Domain Name Server replies are now processed one Resource Record
- (RR) at a time in order to avoid exhausting the DNR's limited pool of memory. This
- allows 2.0.6 to swallow the most verbose BIND 4.9.2/3 ADDAUTH PTR replies
- without encountering an out-of-memory error condition.
-
- • The DNR now only caches A and CNAME RRs from the Answer section. NS RRs
- from Authority and A RRs from Additional are used to recursively follow-up
- references if that's necessary, but they are not stored. This greatly reduces
- the demand placed on the DNR's limited memory pool. It also transforms the
- DNR almost totally into a Stub Resolver (see RFCs 1034 and 1035). As a side
- effect, each new query starts off with only the name server information
- originally configured in the control panel or from a server. This makes the
- choice of which server(s) to contact, and the order in which they will be
- contacted, much more determinate and under the control of the configuring
- administrator.
-
- • Several small memory leaks have been fixed, including a corner case in
- MacTCP 2.0.4 in which a block of memory could be freed twice, causing
- indeterminate problems later on.
-
- • The DNR is now fully up to date in terms of permitted and forbidden
- syntax for domain names.
-
- • Domain name syntax checking has been extended to cover MXINFO and
- HINFO requests; previously only A requests (String To Address) went
- through this check.
-
- Performance:
- ------------
-
- • Previous versions of MacTCP kept track of retransmission timers on a
- per segment basis. If 4 successive segments were dropped due to
- congestion at a gateway, the retransmission of each one would require a
- separate time-out, and each would force an additional exponential back-off.
- Because of this, retransmission time-outs sometimes became excessively
- long. In MacTCP 2.0.6, retransmission of a group of segments does not
- result in further exponential back-offs.
-
- • Under certain conditions, MacTCP 2.0.6 will assume that a duplicate ack
- implies that retransmission of data will be required, and will expedite the
- retransmission process. This often results in much shorter retransmission
- delays when MacTCP is sending data.
-
- Configuration:
- -------------
-
- • Previous versions of MacTCP checked both the source and destination port
- field in Bootp configuration responses, and did not accept the response unless
- the source port was 67 (Bootp Server) and the destination port was 68 (Bootp
- Client). Because the Bootp protocol permits Bootp Relay Agents (which are
- Clients) to relay configuration packets from their own Client port address
- MacTCP failed to accept valid Bootp responses passing through Bootp Relay
- Agents that implemented this feature. MacTCP 2.0.6 now only checks the
- destination port for validity.
-
- • When configuring via Bootp, previous versions of MacTCP saved only the
- last Domain Name Server returned in a Bootp reply. In cases where only one
- DNS server was returned, this didn't matter. When more than one server was
- returned, the one saved (the last one) was usually the least desirable server.
- 2.0.6 is still limited by architectural constraints to using a single
- Bootp-configured DNS server, but it now saves the first one returned - that
- is, the "best" or most desirable server in the list.
-
- • Previous versions contained a bug in the Bootp configuration code for the
- processing of the Default Gateway option that could have led the DNR to
- corrupt any portions of a Bootp reply following that option.